Skip to content

feat(target-allocator): add allowInsecureAuthSecrets option#5088

Open
tillwulfram wants to merge 1 commit into
open-telemetry:mainfrom
tillwulfram:feat/TA-allowInsecureAuthSecrets
Open

feat(target-allocator): add allowInsecureAuthSecrets option#5088
tillwulfram wants to merge 1 commit into
open-telemetry:mainfrom
tillwulfram:feat/TA-allowInsecureAuthSecrets

Conversation

@tillwulfram
Copy link
Copy Markdown

Description:
Currently the TA can only serve discovered auth data, eg. Kubernetes Secrets from a ServiceMonitor with basicauth, over mtls. This great feature would overcomplicate setups for teams who have existing service mesh which already handles the mtls auth between the services or high maintenance for teams who can't use the operator / crds and also for dev setups.
Its configurable bool via config file, CLI flag (--allow-insecure-auth-secrets), or environment variable (ALLOW_INSECURE_AUTH_SECRETS) - allowing the most flexibility so the operator crds can cover this setting and also the standalone helm chart from the targetAllocator.
-> When enabled, a "warn" log will be written at startup that secret are exposed via plaintext.
Defaults to false to maintain backwards compatibility.

A next feature could be that also https can be configured so no "heavy" mtls is needed, but at least the transport is secured.

Testing:
Expanded the tests for the new feature in the config, flags and the server files.
All tests, precommits and lints were successful.

Documentation:
Added the new config parameter to the targetAllocator and a short description how it can be used, for which environments it should be used and which problem it can solve.

@tillwulfram tillwulfram requested a review from a team as a code owner May 17, 2026 22:02
Copy link
Copy Markdown
Contributor

@swiatekm swiatekm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should make this a field on the TargetAllocator CRD rather than force users to go through env variables.

We should also add an e2e test for this functionality, similar to the existing mtls tests.

})
}

func TestAllowInsecureAuthSecrets(t *testing.T) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need these tests specifically for this one config value? Consider adding it to an existing test instead.

}

if s.allowInsecureAuthSecrets {
slog.New(logr.ToSlogHandler(s.logger)).Warn("allowInsecureAuthSecrets is enabled - auth secret values will be served over plain HTTP. " +
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you using slog here, as opposed to using the existing logger directly?

Comment on lines +435 to +444
```yaml
targetAllocator:
enabled: true
env:
- name: ALLOW_INSECURE_AUTH_SECRETS
value: "true"
```

> **Warning:** Only enable this when transport-level security is guaranteed by other means. Without mTLS or a service mesh, auth secrets will be transmitted in plaintext.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of suggesting this, I'd prefer to add a allowInsecureAuthSecrets on the TargetAllocator CRD.

@tillwulfram
Copy link
Copy Markdown
Author

thanks for the feedback @swiatekm! :)
I'll implement the improvements for the tests.
Regarding the other topics I would like to discuss to understand / clarify it. I only implemented slog because I wasn't aware of—or hadn't noticed—any native warning level in logr, and since slog is also used in other files (config, etc.), I based my implementation on that. If the message is supposed to be just an info level and should include "WARNING" or something similar in the message text, I can change that as well.
From what I gathered from our discussion in the previous issue, the CRD adaptation would require too much effort or would be an implementation in a separate pr for such a "niche" topic, and with the three approaches (Env, Args, ConfigMap), we would have covered both the Operator CRDs and also the standalone Helm TA. But if wished I can look into the implementation about the crd field

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ScrapeConfig targetAllocator bad password using basicAuth

2 participants